1. Technical Field
Embodiments of the present invention are related to network switching device design and more specifically to a switch fabric architecture relating to network switching devices.
2. Discussion of Related Art
With the advent of centralized locations for storing data associated with network services (retail services, financial services, communication/social networking services, database services to name only a few), network devices such as switches and routers are designed to very quickly process and route large volumes of network traffic. Such centralized locations are typically referred to as data centers.
FIG. 1 illustrates a typical topology 100 that can be used to implement such a data center. As illustrated in FIG. 1, two redundant Core switches 102, Core switches 0 and 1, are both linked to a number of Top of Rack (TOR) switches 104-0 through 104-m (collectively TORs 104). As is further illustrated, each of TOR switches 104 is linked to a plurality of servers 108 that are typically placed on racks 106. As shown in FIG. 1, TOR 104-0 is coupled to racks 106-1 through 106-n (collectively racks 106), each of which includes a plurality of servers 108. As illustrated, there can be one or more server racks 106 coupled to each of TOR switches 104, with each of server racks 106 including one or more servers 108. Each of TOR switches 104 operate to control the flow of data to and from servers 108 in each of racks 106 to which they are coupled.
TOR switches 104 and Core switches 102 illustrated in FIG. 1 can be modular devices with line card functionality, route processor functionality and switch fabric functionality that are each implemented on separate modules and coupled to a backplane within an enclosed chassis. Alternatively, all of the functional elements included in TOR switches 104 and Core switches 102 described above can be implemented on a single mother board. Depending upon the network environment in which the switches operate. TOR switches 104 and Core switches 102 can be configured to process either or both of Ethernet or IP packets.
FIG. 2 illustrates a generalized block diagram of the functional elements of a switch 200, which can be either one of TOR switches 104 or one of Core switches 102. As shown in FIG. 2, switch 200 includes one or more line cards (LC) 202, one or more route processor modules (RPM) 204, and one or more switch fabric modules (SFM) 208, all coupled to a backplane (BP) 206. The LCs 202 generally operate to receive packets or frames of information from other network devices and process the packets to determine how to forward them to their destination. The RPMs 204 generally run layer-2 or 3 network protocols that, among other things, generate information used to build and maintain switching and routing tables stored on each line card 202. The SFMs 208 generally operate to receive packet segments from the LCs 202 and then switch those packet segments so that they are distributed to their correct destination (destination LC, queue, FIFO, buffer, etc.).
In operation, a packet of information ingresses to LC 202 on switch 200 and information in the packet header is examined to determine how to propagate the packet through switch 202 to its destination (whether the destination is the same switch or a different switch). Typically, the packet is divided into segments and sent to the SFM 208 where they are switched through SFM 208 and delivered to their destination, which can be the same or different LC 202 in switch 200. The packet segments are reassembled and then transmitted by LC 202 to their destination.
Referring again to FIG. 1, when a packet ingresses to TOR 104-0 from a server 108 in Rack 106-0, for example, TOR 104-0 processes the packet header and determines whether the packet's destination is a server located in one of Racks 106 that is coupled to TOR 104-0. For example, the destination may be to a server 108 located on rack 106-n. If the destination is to a server on one of racks 106 coupled to TOR 104-0, then TOR 104-0 can forward the packet to the proper destination server 108 in that rack 106 (e.g., Rack 106-n). In the event that TOR 104-0 is running in an Ethernet environment, TOR 104-0 processes certain information included in an Ethernet header included in each packet. This processing can include a MAC lookup, IP destination address lookup, filtering using access control lists (ACLs) or any other Ethernet packet header processing. Depending upon the amount of Ethernet processing that needs to take place, more or less latency is added by TOR 104-0 in the packets path.
Continuing to refer to FIG. 1, and in an alternative scenario, in the event that TOR-0 determines that the packet received from rack 106-1 has a destination to another one of TORs 104, e.g. TOR-1 through TOR-m, then the packet is transmitted from TOR 104-0 to Core switches 102 (e.g., CS.0 or CS.0), which performs further processing on the information included in the packet's Ethernet header and subsequently forwards the packet to the correct one of TORs 104-1 through 104-m. Further packet processing occurs at the destination one of TORs 104-1 through 104-m for distribution to a correct server 108 on the correct rack 106. In this case, some or all of the information included in the packets Ethernet header can be processed three times along the packets path from the source to the destination (once at the ingress TOR (TOR-0 in the above examples), a second time at a Core switch 102 and a third time at the egress one of TORs 104-1 through 104-m), thus potentially tripling the path latency associated with Ethernet packet header processing.
Therefore, there is a need to develop improved architectures for network data switching systems.